When an error or exception occurs in a software application, the problem is often recorded in a log file. This log file can then be analyzed in order to determine the cause of the problem and to take corrective action to prevent the problem from occurring again. However, in existing logging solutions the data that is recorded only takes into account the top method on the call stack at the time of the error or exception event. It does not take into account other methods on the call stack or other contextual data.
In many cases, when a problem is logged, it is necessary to try to recreate the problem to determine the exact cause of the problem. This is typically due to the log missing relevant information, such as context when the problem occurred. Recreating the problem is expensive, however, because often problems are difficult to recreate and they usually involve enabling tracing in the application, which hinders performance.
To prevent the need to recreate a problem, it is desirable to capture as much relevant information as possible about an error or exception condition. If enough information is generated when the error or exception occurs, then recreating the problem should not be necessary. However, it is not usually possible for an exception monitoring program in an object oriented code (OOC) such as Java, when catching an error or exception, to know the context in which the program is called (e.g. by a thread in a WebContainer, by a WebServices container, by a Portal engine, by an Enterprise Java Bean (EJB), by an EJB container, etc.). Context such as Webcontainer status, Webservice Container